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The FINDSPACE problem is a computationally hairy but well-defined sub- 
problem of the robot problem. The genesis of the problem name is a function 
in Terry Winogra.il ’& block nan ip motion program* This function assumes a 
model of the world consisting of a table with bricks piled on it and takes 
arguments describing an object to be added to the scene by placing it on a 
specified surface (either the table Or the top of an existing block]. If 
there is room on the specified surface for the given block> FINDSPACE re¬ 
turns a specification of the available space. If there is no available space* 
the FIND&PAGB function returns NIL, Associated with the FINDSPACE program must 
be routines to update the data base, i,e, the environmental model, when an 
object is moved in., added to* or removed from the scene. Indeed, since these 
routines will be called relatively rarely compared with accessing of the 
data base, it is reasonable that they be expensive and compute a complex 
representation of the object whose status is being modified if this ziakLes 
FINDS-PACE sufficiently easier, I became involved in the FINDSFACE problem 
because- Tarry's program hag certain restrictions (which 1 will described 

later) which make it fairly useless for dealing with real world situations, 

In the real world, a FIND&PACE solution, though it may be heuristic M 

aust be conservative That is* it must not make the mistake of finding 
space when there is none, though it may he occasionally wrong by failing 
to find space when there is some. This is the case because the robot hand 
may be damaged by attempting to push one object through another. This dic¬ 
tum can best he understood by realizing that the stubbing of a toe reflects a 
failure of the human FINDSPACE, 

The FIM15PACE problem has several SUbproblCmS to be solved, Elow do we 
represent the objects in the world model so that It is possible to solve the 
problem with a reasonable degree- of efficiency? How can we propose 0 likely 



space for ais object? And given a proposed likely space, bow can we verify 
Its safety to the desired degree of conservetiveness without, rejecting too 
many good answers? Thus the FlNDSPftCE program may be divided into two sub¬ 
routines; a proposer and a verifier, Although this paper is basically about 
verlfieTs, I will take a short excursion into the realm, of pToposers- The 
simplest proposer [which Is employed in tfinograd |, s program) is a random 
solution generator. It generates solutions randomly, constrained only by 
the input data [the object and the surface to put it on) without regard to 
the model. It then passes this proposed solution to the verifier. Such a 
method works very well in a sparse space. A more sophisticated proposer could 
have some description of the larger areas of free space, roughly analogous 

I 

to a free storage list in a storage allocation system fqr a computer, The 
problem with this- idea is that I haven’t seen any scheme for doin£ this that 
doesn’t become very frag^nted quickly ■ Another possible scheme [currently 
implemented by Eugene Frsuder) is a division of space into a set of buckets 
which are marked when they aTe occupied] thus only proposals of unmarked 
buckets may be made., 

Getting to the verifier^ various restrictions may bo imposed on the 
problem to make it more tractable. In Winograd’s program, for example, the 
only objects allowed are rectangular prisms * hereafter called bricks [he 
does allow pyramidsbut from FIYDSPAjCE 1 s point of view they arc bricks con¬ 
taining the pyramids)j with all dimensions parallel to the coordinate axes; 
furthermore, no brick may ever be rotated. This model is too restricted for 
a real world robot since it cannot expect to find its world all lined up 
for it. In this model an object is represented as a single point [the lower, 
forward j loft hand comer) and a set of dimensions [lengthy width, and depth). 
The central function in Kinograd'fi verifier is a function called GROW p which 



takes a proposed point and grows it along the direction of the coordinate axe? 
to become a rectangle of maxinal size which intersects no other object, It 
then tests the sire of the result to see if it fits the given object , and 
if it does it returns the center of the grown region, 

I have written a verifier, called RCLEAR(recursive clear), which allows 
the model to contain bricks in any orientation, thus relaxing the most Im¬ 
portant restriction of the previous program. In the model each brick is 
represented as a list (E^ El E2 EJ), where P is the centroid of the brick and 
El* E2, E3 represent the edges of the brick, Ei is & list (d v), where d is 
the square of the length of the corresponding edge and v is the unit vector 
pointing in that direction. The general philosophy of RCLEAR is: in order 
to determine if the given object could fit in the given place in the scene* 
imagine it in place and check if it Intersects any other object. The 
critical function here is one called DISJ0JNT1, which takes two representa¬ 
tions of bricks and returns T if they are disjoint and NIL otherwise. Upon 
entry* DISJOINT! computes the radii r, and r ? of the smallest spheres com¬ 
pletely enclosing each brick and the distance d between the centroids of 
the bricks (they are the centers of the spheres). If d^+r., the bricks are 

disjoint. If not, it constructs rj and rl r the radii of the largest spheres 
about the centroids completely enclosed by the bricks (they aTe half of the 
length of the minimum side). If d,<r'+r£ ^ brick? overlap and the algorithm 
returns NIL- If neither test is passed, there is uncertainty in the result* 
and to remove this uncertainty we must apply a finer filter. We find the 
largest edge, say £1 of brick ftl, of all six edges of the two bricks. Ne 
then, divide EH into two bricks, Bll and B12* by halving EI. DISJOINT) then 
roturns (AND (DISJOINT! 611 B2] (DISJOINTl B12 B2)). 



Note how clever this algorithm Is; If at aay level it Can decide 
immediately that the objects are disjoint by applying, a gross test ^ it does 
so. Furthermore, the recursion lets it zero In on the trouble spot very fast. 
For example. If the bricks are close together at one end of one of them, 
then it will recurse deeply only on subbricks at that end. Another thing to 
note is that each test is very fast, so it never Considers Very long two 
bricks at opposite ends of the table or obviously overlapping. In factj, the 
harder it is to decide the question, the harder DISJDINT1 works. Furthermore h 
It never takes a square root because it always keeps its distances squared, 
DISJOIKTl, however, has One serious difficulty; It never terminates if the 
objects just touch, rather than overlap or are separate. To avoid this there 
is an extra parameter (a free variable called FliZEPS (the epsilon of f^tiness)} 
which it compares to the length of the maximum edge before it recurses and 
if MWC^FUEEPS it conservatively returns failure. This also makes FINDSPACE 
somewhat hairier because it must avoid applying DISJOINT! to the proposed 
spot and the- brick whose surface we are finding space on- 

Anothcr problem with ECT.F-Aft is that it too is severely restricted in 
that it only works for bricks and would be difficult to extend to other classes 
of objects* ha could write a version of DISJOINTS which worked for tetra- 
hadre, since it is very easy tg calculate the ciTcuascrihed and inscribed 
spheres of a tetrahedron. Furthermore, a tetrahedron can he split easily 
into tetrabedra, naking the recursive step possible* Since any polyhedron 
may be triangulated into tetrahedra, it becomes possible to represent any 
polyhedron as a union of tetxahedr&. Thus two polyhedra are disjoint if and 
only if all the pairwise combinations of a tetrahedron frora each are disjoint r 
This is very general but it suffers froiz the disadvantage that the algorithm to 
triangulate an object may be in general very hairy t This is not so terrible 



ii we are dealing with many objects because th-e data base building function 
may be arbitrarily expensive s-iaace most objects are stationary. Another dis¬ 
advantage is that an object such as a brick will be represented by say 5 
(I do net know if this is minimal) tetrahedra, and thus a new program would 
be- perhaps 25 times as expensive as RCIEAK, Although this is only a con¬ 
stant factor ? it looks pretty bad to me. 

Instead of going all the way to arbitrary polybcdr-a, we can pet some 

mileage by restricting ourselves to arbitrary convex pglyb^dra, Any such 
object can be represented as a system of linear inequalitl-es, each of which 
determines the halfspace bounded by a plane of which a face of the object Is 
a segment and which is true on the interior of the object. Thus the ques¬ 
tion o£ whether or not two convex pglybedTa std disjoint is the same as 
the question of when a system gf linear inequalities (the loi ion. of thft sys¬ 
tems which determine each object) is inconsistent. Until the recent visit 
of Michael Rabin* 1 thought that this problem was very hard^ and 1 did not 
consider it as a possible approach, Ur. Rabin„ however^ showed me that ojic 
could consider this a Linear programming problem as follows * bet two con¬ 
vex poLybedTfi P and Q bo represented by the following inequalities-* where 
f^i*0 [f is the equation of the ith face of p (qj . 

f p 1 ‘ P 1 +p l* XtF l/* P I= f pZ' P 2* P 2i lt * P 2y ) " p 2 a 1 - 0 ' etC ‘ 

Since F i? an objectJ it is not inconsistent and must have a solution, say 
(x y t j which satisfies it, Thus wt can employ linear programming tech¬ 
niques* the Simplex method* for example, to find a solution of L 1 which op¬ 
timizes the form [we actually need not optimise we can Stop when- 

over f u ]_>OJi. If the best we can do leaves fq] negative* then the systems 



arc mituBLly inconsistent and thus the objects are disjoint r Tf we can i^aT<e 


f 1 positive, then we have a solution of the constraints {f .Hi P and we 
can use linear pi'ogTamming to repeat the process on £ j with respect to 
the new constraints Cf^iJU P* We continue this process until we come up 
with an inconsistency or until ail the f j are satisfied* in which case we 
decide that F and Q aro simultaneously satisfiahlc, i L c_ they int*tscct, 


This turned out to be a common linear programming technique which I 

"i 

found formalised in Linear ami Convex Programming by Zukhovitsky and Av¬ 
dey ova p as an algorithm [chapter 2*2 - The Simplex Method £qt Finding a 
Basic Solution fox a System of Linear Inequalities). 1 have realized a form 

of this algorithm in a program called FEASGEN, which generates a solution to 
a system of linear inequalities if there is one. I have embedded this pro- 
graft in a verifier called SIMFLLLAR, Comparisons in efficiency of EC LEAK 


and SIMPCLLAR are included in the appendix. It is evident ¥ however a that a 
great daal might be gained in the efficiency of FEASGEN by a judicious 


choice of the t" . to be tested at any time, Furthermore, if at any time 

qi 

we get a point which satisfies all the remaining V {the regions have 
the point in common) we want to know that immediately^ and in fact if we 


□vct Cose up with a point which satisfies any f . besides the f . we 

r r qp qi 

arft Currently considering we want to bring f into the list of constraints 
so bS to narrow Out search space as fast as possible. I Illustrate this 


as followSr P and Q intersect over the urea CIJ. Suppose that the ini¬ 


tial proposal we have for P la the vertex A (a worst case), When we choose 
a function corresponding to a side of Q to increase with respect to the 
constraints of P, it would not be optimal to choose E1F or FG because they 
are both satisfied everywhere on E, If^ however B we increase lIG {or EH) 



with, respect to P 



Off ver¬ 
tex A]. In the rifrxt step the only pi Line worth increasing is EU ¥ which gets 
us a solution. The algorithm which I have coded contains ail of these 
hacks and thus dees not waste time with irrelevancies. The only real over¬ 
head is that it carries EF and Ffi along throughout the calculations because 
1 do not know how to decide that they aTc subsumed by F, 

Why have we gone to So much trouble to find a clever method for 
determining the disjoint ness of objects; sorely w-e can do this simply by 
analytic geometry? If two objects intersect such that one is not wholly 




contained within the other, then an edge of one most intersect a face of 
the other. The &truightforward way to check this is to determine the 
intersection of every edge of one with every face of tlie other by solving 
three simultaneous equations in three unknowns {two defining the edge and 
the third, the face] and then checking that the resulting point is in 
the correct range, (by Cramer* s rule,, a 3x3 set of equations takes four 
determinants, each taking 14 operations; but by collecting common sub¬ 
expressions, this can be reduced to a total of 47 operations.) Thus, 
since a brick has six faces and twelve edges, this method would require 
144 such testg {plus a check that one vertex of each is not in the other 
to exclude the wholly contained case) to determine that two bricks aTe 
disjoint. If they arc not disjoint the condition would bo determined 
earlier by seme particular edge intersecting a particular face in range, in 
the worst case d however, this tost would require more than 144x47"67Sii 
operations (we have ignored the range tests) to prove two bricks disjoint. 

The linear programming method should take about it iterations, for n 
the number of constraints, to determine feasibility. Mow each iteration is 
a Jordan elimination on an nx(d+i) matrix, where d is the dimension of 
space. A Jordan elimination takes {n-Dxd subtractions and 2xfn-l)xd 
multiplications for a total of 3x(n-l)xd operations. So for bricks, 

FEASGEN should take about 3x11 *3x1 2= ] ] fif3 operations to determine di s joist - 
ness. Though I don't know about the worst case, the data on FEASGEfi, as 
explained in the appendix, seems to indicate that the worst case is when 

the objects are disjoint, which takes almost a constant amount of time 
to compute, whereas the- amount of tjcie it takes to decide that two objects 
are not disjoint is always less and varies considerably, just as in the 



exhaustive intersection method examined earlier. This would lead me f -0 
surmise., since the observed behavior of FliAStilJN matches the a priori 
behavior of the unwritten exhaustive search, that PbASGEN is really only 
a very clever bookkeeping method for doing the exhaustive search, with 
built-in range-testing and wholly-within case exclusion. 

Nick Horn and r have slightly investigated other methods, For ex¬ 
ample, we have conjectured, hut not proved, that any two disjoint convex 
polyhedra can be separated by a plane determined by a vertex of one and 
an edge Of the other, Since ft is easy to determine if two points .'.re 
on the same side of a plane, this may be a useful technique, but wc arc 
not yet convinced. 



Appendix: A Comparison -Of RCLEAR and SIMPCLELAR 


Besides implementing RCLEAR and SLMFCLUAR„ I also implemented a testing; 
procedure to Bake it passible to compare their behavior. The testing pro¬ 
gram generates a brick with a rsnd<m lengthy widths depths position^ arid 
orientation in a sharply delimited cubital space. It then applies HOLLAR 
arid 5IMPCLMR to this brick L If thfly disagree, the program typos oust an 
error message and halts until told to proceed. If they agree that the ne^ 
brick is not clear of other bricks in the space, it repeats the process. 

[£ they agree that the new brick is clear of all other bricks in the space, 
it inserts the new brick into the space and repeats. Since both RCLFAR and 
SIMPCLEAR work by testing the pairwise disjointness of their argument ?md 
the bricks in the Model. a coalmen parameter which m&y be used to analyse 
the performance of the program is the average time per pairwise comparison 
of two bTicks during the verification process. 

The pTograns wore written in LlSF and nln interpretively (due to the 
fact that the Compiler often produces hard-to-find bugs, programs are not 
worth compiling UalleSS they ate to be run many times So that the time saved 
justifies the resultant e^tfa debugging tire). They therefate ran with a 
Monstrous overhead (especially since they spend much of their tieie number- 
crunching) and the time pet brick-pair comparison ranged freo ,1 to 10 s-ec, 
RCLEAR had much bettor best oasos and r.uch worse worst oases in general than 
SIHPCLEAR. PuxthCTmoro ? a^ spaoc filled up with hTicks ? RCLEAR bec^m-e bett-er 
and better with respect to SH^RLLEAR. if the new brick was destined to be 

see grapfi and raw data at end of paper. 



discovered clear, it is likely that RCLliAR would spend less than .3 sec., 
finding that out. This is probably due to th£? fact that RCLEiAR hardly 
blinks dn eyelash at a brick. far away because tt will be flushed without 
any recursion, allowing RCLEAlt to concentrate on the more difficulty close- 
by cases. Sometimes * however, a bed case can happen in which RCIEAR re- 
curses for a long time. These cases, however,, are rare, and tend to get 
averaged out when the number of bricks is larger They also tend to happen 
nore often when, the brick is- to fr© rejected Tather than accepted. This 
tends to suggest that the Circumscribed spheres buy mere than the inscribed 
sphere^ per recursion^ I think that because 5IMPCLEAH does more arithmetic 
than RCLEAR it was hurt moTC by LISP inefficiency and that if both wcto hand* 
compiled into MIDAS* SlMPCLtAK would be midi more competitive. Perhaps the 
best algorithm would combine the two ideas, using the spheres to weed out 
obvious cases and turning over tough nuts to FEASGEK, 














































































